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ABSTRACT 


Every  year  the  E>epartment  of  Defense  (DoD)  spends  between  24  and  32  billion 
dollars  on  software  alone,  with  maintenance  costs  comprising  the  majority  of  this  figure. 
Recent  studies  have  indicated  that  an  effective  solution  to  help  curtail  development  and 
maintenance  costs  is  to  capture  the  rationale  behind  systems  requirements  and  designs,  and 
use  this  information  throughout  the  life  cycle.  This  thesis  explores  the  use  of  REMAP/MM 
and  multimedia  based  design  rationale  management  systems.  Based  on  a  case  study,  a 
detailed  example  illustrating  to  use  REMAP/MM  in  various  systems  development  activities 
is  presented. 
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I.  INTRODUCTION 


The  software  budget  for  the  DoD  is  becoming  a  larger  part  of  the  entire  budget  each  year. 
Currently  it  is  estimated  that  DoD  is  spending  between  24  billion  and  32  billion  dollars  on 
software  costs  alone  (USAGAO,  1992),  accounting  for  between  8  and  1 1  percent  of  the  entire 
DoD  budget.  However  the  amount  of  money  the  DoD  spends  on  software  does  not  tell  the  whole 
story.  The  DoD,  like  most  software  dependent  companies,  these  days,  is  quickly  approaching  the 
"maintenance  wall".  As  budgets  tighten,  the  maintenance  costs  of  installed  systems  are  using  iq) 
the  available  resources,  significantly  affecting  new  systems  development  (Sprague  and 
McNurlin,  1993).  During  the  1970s,  maintenance  of  software  accounted  for  between  35  and  40 
percent  of  the  software  budget  for  an  information  system  organization.  This  number  jumped  to 
^proximately  60  percent  during  the  1980s.  It  is  estimated  that  maintenance  costs  today  comprise 
70  to  80  percent  of  the  DoD  software  budget.  As  a  result,  DoD,  as  well  as  many  companies,  are 
seeking  a  major  shift  in  the  way  they  build  and  maintain  software  in  order  to  drive  maintenance 
costs  down.  (Pressman,  1992) 

A.  THE  DESIGN  RATIONALE  SOLUTION 

Recent  research  suggests  that  in  large  scale  computer  systems,  the  c{q>ture  and  use  of  the 
design  rationale  can  significantly  improve  software  development  and  maintenance  productivity 
(Ramesh  and  Dhar,  1992).  Design  rationale  serves  multiple  purposes;  definition  of  unstated 
assumptions,  clarification  of  dependencies  amoi^  artifacts,  decision  constraints,  and  justification 
or  validation  of  design  decisions  (Gruber  and  Russell,  1992).  The  effective  c{q)ture  and  use  of 
this  design  rationale  should  be  considered  a  vital  part  of  the  design  process. 


1 


B.  WHY  RATIONALE? 


Over  half  of  the  cost  of  development  of  complex  computer-based  information  systems 
can  be  attributed  to  decisions  made  in  the  requirements  and  design  phases  of  the  software 
development  process  (Walz  et  al,  1993).  Understanding  system  requirements  and  design 
rationale  during  the  later  stages  of  the  development  life  cycle  can  be  useftil  in  managing  system 
change  and  can  facilitate  the  reuse  of  certain  components,  helping  to  decrease  software  costs. 

For  instance,  the  design  of  any  system  involves  groups  of  people  working  through  various  phases 
of  the  development  life  cycle.  Within  each  of  the  groups,  every  member  brings  individual 
viewpoints  and  expertise.  Individual  team  members  do  not  have  all  of  the  knowledge  required 
for  the  project,  and  must  acquire  additional  information  before  accomplishing  productive  work. 
Group  interaction  involves  information  exchange,  communication,  and  the  resolution  of  various 
issues  between  the  team  members.  A  primary  outcome  of  this  group  interaction  is  design 
rationale;  the  foundation  on  which  a  project  or  system  is  built. 

Due  to  the  size  of  most  projects,  development  timelines  can  easily  stretch  into  several 
years.  During  this  time  period,  most  development  teams  experience  turnover  of  personnel.  As 
the  individuals  in  the  group  change,  the  dynamics  of  interaction  between  the  members  also 
change.  Additionally,  the  new  members  of  the  grotq}  n^  to  be  updated  on  the  progress  of  the 
project,  so  that  they  may  better  understand  their  own  role  within  the  group.  Research  has  shown 
that  a  great  deal  of  the  vital  information  given  to  a  team  during  the  requirements  phase  of 
development  is  lost  (Walz  et  al,  1 993).  Design  decisions  can  become  completely  lost  from  one 
meeting  to  the  next.  Even  i^en  individuals  remember  that  a  certain  decision  has  been  made. 
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they  often  find  it  difficult  to  recreate  the  rationale  behind  the  decision  ("Why  are  we  doing  it  this 
way?"). 

C.  THE  DIFFICULTY  IN  CAPTURING  DESIGN  RATIONALE. 

C^turing  design  rationale  is  a  difficult  and  time  consuming  task.  In  particular, 
determining  \^diat  aspects  of  design  rationale  are  worthy  of  ct^ture  requires  a  great  deal  of  insight 
and  experience.  The  more  complex  the  system,  the  more  difficult  it  is  to  trace  the  decision 
process  during  any  phase  of  systems  development.  Capture  of  design  rationale  needs  to  be  as 
detailed,  and  complete  as  possible.  The  capture  methods  must  prevent  ambiguity  in  the  raw  data 
as  much  as  possible,  as  well  as  be  as  unintrusive  as  possible.  This  will  allow  the  user  the 
opportunity  to  make  his  own  interpretations  of  vdiat  the  data  means.  (Ramesh  and  Sengupta, 
1994) 

D.  WHY  MULTIMEDIA? 

The  use  of  multimedia  in  capturing  design  rationale  provides  three  benefits.  First, 
multimedia  is  particularly  useful  in  capturing  physical  gestures,  body  language  and  other  forms 
of  constructive  conmiunication  among  members  in  the  design  group  (Ramesh  and  Sengupta, 
1993). 

Second,  once  captured,  these  narratives  can  then  be  used  by  different  individuals  for 
different  purposes.  For  example,  a  user  interested  in  the  reasoning  behind  a  particular  artifiict 
would  use  the  videot^  of  a  design  session  quite  differently  fix>m  a  user  interested  in  learning 
about  the  points  of  view  of  the  respective  stakeholders. 

Finally,  the  unprocessed  information  that  multimedia  provides  allows  the  user  to  interpret 
and  assign  their  own  evaluations  of  the  decision  inx>cess.  Also,  design  decisions  are  often 
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characterized  by  assumptions  that  are  not  stated  explicitly,  but  must  be  inferred  from  the  context 
of  the  discussion.  A  richer  context  for  understanding  the  collaboration  mechanisms,  process  and 
culture  in  design  groups  can  enable  the  user  to  interpret  the  rationale  behind  the  creation  of 
artifacts.  (Ramesh  and  Sengupta,  1993). 

E.  RATIONALE  AND  MULTIMEDIA 

A  model  that  has  been  successfully  used  to  structure  design  rationale  is  the  Issue  Based 
Information  Systems  (IBIS)  model  (Rittel,  1973).  However,  informal  representations  of  design 
rationale,  such  as  a  multimedia  record,  have  shortcomings  too.  Such  information  can  not  be 
easily  indexed  and  retrieved.  Further,  the  potential  for  automated  reasoning  with  such 
knowledge  is  severely  restricted.  Recent  research  suggests  that  a  semiformal  representation  that 
provides  a  structure  to  the  design  rationale  information,  in  addition  to  multimedia,  would  be 
appropriate  for  design  rationale  capture  and  use  (Ramesh  and  Sengupta,  forthcoming). 

The  REMAP/MM  system  currently  under  development  at  the  Naval  Postgraduate  School 
in  Monterey,  California,  is  an  attempt  to  couple  an  extended  IBIS  model  with  multimedia.  The 
REpresentation  and  MAintenance  of  Process  knowledge  (REMAP)  provides  a  conceptual  model 
and  mechanism  for  the  representation  and  reasoning  of  design  rationale  knowledge  (Ramesh  and 
Dhar,  1992). 

F.  METHODOLOGY 

In  this  thesis,  we  present  an  example  to  illustrate  the  use  of  multimedia  in  the  capture  of 
design  rationale  during  system  development.  The  example  consists  of  segments  of  design 
rationale  from  a  system  development  exercise  in  a  utility  company.  The  example  and  the 
multimedia  segments  used  in  this  document  are  based  on  a  case  study  in  the  utility  industry. 
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These  detailed  scenarios  describe  the  capture  of  design  rationale  in  the  requirements  engineering, 
systems  analysis,  and  detailed  design  phases  of  system  development. 

G.  LIMITATIONS 

The  example  is  limited  in  that  only  a  few  snapshots  of  the  development  process  have 
been  captured.  In  order  to  fully  document  and  capture  all  of  the  design  rationale  of  a  project,  a 
full-fledged  longitudinal  should  be  carried  out.  This  example  is  intended  to  provide  a 
proof  of  concept  model,  not  a  comprehensive  design  rationale  record.  An  important  issue  not 
addressed  in  the  research  is  the  detailed  evaluation  of  the  usefulness  of  multimedia  design 
rationale  capture  mechanisms. 

H.  OUTLINE 

The  next  section  provides  an  overview  of  the  REMAP/MM  model  and  system  and 
introduces  the  example.  Chapter  3  provides  a  detailed  description  of  REMAP/MM  use  in  three 
system  development  activities.  The  focus  of  the  discussion  is  to  illustrate  the  REMAP  model 
and  multimedia  in  capturing  and  integrating  design  rationale.  The  final  chapto*  provides  the 
conclusion  and  recommendation. 
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II.  A  REMAP/MM  EXAMPLE 


A.  REMAP/MM 

The  objects  in  the  REMAP  model  include  requirements,  the  primitives  of  IBIS  (issues, 
positions,  arguments,  assumptions),  as  well  as  d«:isions.  Requirements  represent  the  goals  or 
objectives  of  the  design  problem.  Issues  are  problems,  concerns,  or  questions  relating  to  specific 
requirements.  Positions  are  solutions  >^ch  respond  to  an  issue.  Arguments  are  statements  that 
support  or  object  to  positions.  Assumptions  behind  arguments  are  also  effectively  captured. 
Decisions  are  the  result  of  the  deliberation  of  issues.  These  relationships  are  illustrated  in  Figure 
1  below. 


Figure  1 .  REMAP  Model.  Source  Ramesh  and  Dhar,  1992. 
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REMAP/MM  is  a  multimedia  extension  of  the  model.  REMAP/MM  supports  the  capture 
of  design  rationale  by  providing  a  graphical  user  interface  for  the  design  team  to  use  during  the 
conduct  of  their  deliberations.  It  also  provides  a  mechanism  for  the  hyperlinking  of  multimedia 
objects  to  design  rationale.  For  example,  multimedia  clips  that  elaborate  issues,  arguments, 
positions,  and  decisions  that  a  design  team  encounters  are  stored  in  an  interactive  document,  the 
REMAP/MM  model.  The  user  can  explore  the  document  by  selecting  buttons,  highlighted  text, 
or  other  objects  that  are  linked  to  multimedia  data  such  as  sound  clips,  graphics,  or  even  video 
clips.  With  such  a  document,  the  user  can  view  issues  or  arguments  that  have  been  captured,  and 
can  follow  the  logic  of  why  a  decision  was  made. 

B.  AN  EXAMPLE  OF  REMAP/MM  USE 

In  the  example,  we  consider  a  hypothetical  software  developn^nt  team  engaged  in  the 
design  of  complex  service  process  ordering  system  for  a  local  power  and  utilities  company 
located  in  Duval  County,  Florida.  The  system  will  be  using  a  centralized  telephone  answering 
service  center  that  is  connected  to  a  large  number  of  field  stations  via  an  on-line  computer.  The 
team  includes  all  of  the  important  stakeholders,  such  as  management,  engineering,  and  customer 
relations.  The  primary  task  of  the  development  team  is  to  clearly  articulate  the  various  system 
requirements  with  respect  to  each  stakeholders  point  of  view.  Each  stakeholder  comes  to  the 
design  team  with  different  perspectives  and  requirements.  For  instance,  the  engineers  are 
interested  in  efficiently  screening  service  request  tags  to  assist  in  determining  power  otitage 
locations,  and  customer  relations  is  concerned  with  being  able  to  update  clients  quickly  and 
effectively  when  service  calls  are  received. 
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The  example  is  intended  to  illustrate  that  by  using  REMAP/MM  during  requirements 
definition,  analysis,  and  design  of  the  system,  design  rationale  can  be  effectively  captured.  The 
team  will  be  capturing  a  history  of  the  project  that  can  be  accessed  and  examined  long  after  the 
team  members  have  moved  on  to  other  jobs  or  locations.  A  full  understanding  of  the  design 
rationale  of  the  system,  along  with  a  better  insight  of  the  systems'  original  intent,  enhances  the 
ability  to  modify  the  system  at  a  later  time. 
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m.  IMPLEMENTATION  OF  THE  REMAP/MM  MODEL 
A.  USE  OF  REMAP/MM  IN  REQUIREMENTS  ENGINEERING 

During  the  requirements  phase  of  a  {noject,  detailed  knontdedge  of  the  background  and 
history  of  the  system  is  required  in  order  to  make  sound  decisimis  concerning  the  system's  design 
requirements.  For  example,  ^en  a  system  designer  is  building  a  new  user  interface,  s/he  should 
have  a  deep  understanding  of  how  the  interface  would  be  used,  and  ^^liat  the  potential  users  will 
need  to  effectively  perform  their  jobs.  This  portion  of  the  example  illustrates  how  REMAP/MM 
could  be  used  during  the  requirements  phase  to  effectively  capture  this  essential  background 
information.  The  following  represents  a  hypermedia  document  that  may  be  linked  to  the 
requirements  hierarchy  in  REMAP.  Highlighted  words  in  die  document  have  hyperlinks  to 
multimedia  segments.  In  this  section,  following  a  highlighted  word,  the  section  and  paragnqih  or 
figure  that  is  hyperlinked  to  that  word  is  shown  in  parentheses.  By  navigating  through  such  a 
document,  the  user  can  achieve  a  comprehensive  understanding  of  the  requirements  of  the 
system. 

1.  Background  Information 

When  the  power  company  first  began  providing  power,  its  clients  were  located  in  the 
downtown  Jacksonville  area.  As  the  city  grew  and  eiqianded,  outlying  cities  such  as  Jacksonville 
Beach,  Neptune  Beach,  and  Orange  Park  were  incorporated  into  the  company's  power  grid, 
making  Jacksonville  the  largest  geographical  city  in  the  United  States.  Today,  the  city  has 
expanded  to  include  all  of  Duval  County,  an  area  of  nearly  840  square  miles.  The  city  has 
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experienced  a  population  growth  rate  of  nearly  28  percent  in  the  past  ten  years,  and  power 
demands  have  increased  at  a  similar  rate. 

To  improve  the  service  to  this  expanding  city  ^le  dealing  with  company-wide 
down-sizing,  the  power  company  has  determined  that  an  automated  service  order  processing 
system  is  the  most  economical  solution.  This  new  system  must  provide  a  more  efficient  means 
of  handling  calls  from  the  customer  for  maintenance  and  emergency  service,  and  allow  the 
company  to  dispatch  troubleshooters  in  the  most  effective  manner. 

Presently,  the  power  company  operates  four  regional  centers.  Each  center  consists  of  3-5 
phone  Service  Operators  (see  Section  A,2)  u4io  answer  calls  from  within  their  service  area. 
These  operators  provide  the  customer  with  a  variety  of  services,  arrange  electrical  service  start  or 
stop  dates,  answer  any  billing  question  the  customo’  might  have,  as  well  as  take  any  trouble  call 
information  from  the  customer  and  forward  the  information  to  the  service  dispatcher.  The 
Service  Dispatcher  (see  Section  A, 3)  prioritizes  daily  work  schedules,  assigns  jobs  to  field 
units,  and  monitors  the  progress  of  all  field  workers.  The  field  workers  have  to  coordinate  there 
work  with  the  distribution  operator.  The  Distribation  Operator  (see  Section  A,  4)  coordinates 
all  field  maintenance  from  a  central  location. 

The  new  system  must  allow  the  company  to  expediently  dispatch  their  limited  number  of 
linesmen  more  effectively.  When  a  service  call  comes  into  the  center,  a  Mnltipiirpose 
Customer  Service  Order  (see  Figure  10)  or  service  ti^  is  generated.  This  tag  contains  all 
relevant  information  about  the  customer  service  request.  When  there  is  a  large-scale  power 
outage,  thousands  of  these  tags  can  be  generated.  In  order  to  dispatch  the  limited  number  of 
troubleshooters  to  the  most  likely  source  of  the  outage,  the  tags  must  first  be  numually  sorted  by 
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geographic  area.  Once  these  tags  are  sorted,  they  must  then  be  cross-referenced  with  a  power 
Grid  (see  Section  A,  5)  mq)  according  to  substation  and  feeder  lines .  From  this  map,  a  more 
precise  localization  of  wi  .ere  the  trouble  is  can  be  determined.  Since  this  is  all  performed 
manually,  it  can  typically  take  several  hours  to  localize  and  dispatch  troubleshooters  to  the 
proper  area. 

With  the  Current  Switching  Method  (see  Section  A,  7),  switches  must  be  manually 
opened  and  tested  to  determine  if  they  are  indeed  the  trouble  spot,  or  the  problem  exists 
someMdiere  else  along  the  line.  Once  the  exact  location  of  the  trouble  has  been  determined,  the 
troubleshooters  can  begin  working  on  the  solution  to  the  problem.  With  the  current  system,  it  is 
not  uncommon  for  1 S-24  hours  to  pass  before  power  can  be  restored.  With  the  installation  of 
the  Intelligent  Switches  And  Fuses  (see  Section  A,  8),  the  power  company's  goal  is  to 
completely  automate  the  service  system.  Each  client's  address  will  be  linked  to  a  particular  fuse 
or  switch,  allowing  the  computer  to  expediently  localize  the  trouble  spot.  The  Intelligent 
Switches  And  Fuses  will  allow  for  some  of  the  repair  work  to  be  completed  remotely.  The 
distribution  operator  needs  simply  to  switch  the  intelligent  switch  on  or  off  over  the  phone.  This 
will  allow  for  more  expedient  troubleshooting  before  having  to  dispatch  woikers  to  the  field. 

This  new  system  must  provide  a  more  efficient  means  of  handling  the  processing  of  customer 
maintenance  request  status.  Once  the  troubleshooters  are  on  site,  they  must  assess  the  situation 
and  notify  the  regional  center  of  the  estimated  time  that  will  be  required  to  fix  the  problem.  This 
information  is  currently  first  passed  to  the  dispateher  firom  the  linesmen.  From  there  it  is 
forwarded  to  the  service  center  operators,  time  permitting,  Mdiere  it  is  then  posted  on  a 
chalkboard  so  the  operators  can  inform  calling  customers  of  the  estimated  time  until  their  service 
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is  restored.  The  linesmen  then  coordinate  with  the  distribution  operator  to  ensure  that  they  can 
safely  perform  the  maintenance  without  endangering  other  workers  or  themselves. 

Finally,  after  the  woik  has  been  completed,  every  person  who  called  in  must  be  contacted 
to  determine  if  their  power  has  been  restored.  If  their  power  is  not  back  on,  the  entire  process 
must  be  repeated. 

2.  Service  Operator 

Presently,  the  power  company  operates  four  regional  centers.  Region  One  (see  Figure  3). 
Region  Two  (see  Figure  4).  Region  Three  (see  Figure  5).  Region  Four  (see  Figure  6).  Each 
center  consists  of  3-5  phone  operators  wdio  answer  calls  from  within  dieir  service  area.  Service 
Operator  Video  (see  Figure  2).  These  operators  fnovide  the  customer  with  a  variety  of  services, 
arrange  electrical  service  start  or  stop  dates,  answer  any  billing  question  the  customer  might 
have,  as  well  as  take  any  trouble  call  information  from  the  customer  and  forward  the  information 
to  the  service  dispatcher. 


Figure  2.  Video  of  Operator  servicing  calls. 
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Region  Three 


Region  Four 


North  ofMO,  East  of  1-95 


Figures.  Bitmq)  of  Region  Three. 


South  of  I-IO,  East  of  the  St  Johns  River 


Figure  6.  Bitmap  of  Region  Four. 
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3.  Service  Dispatcher 

The  service  dispatcher  plays  a  vital  role  within  the  maintenance  system  of  the  power 
company.  Service  Dispatcher  Video  (see  Figure  7). 


Figure?.  Video  of  Service  Dispatcher. 


Due  to  the  extremely  large  Geographic  Area  (see  Figure  8),  that  the  company  serves,  a 
great  deal  of  coordination  and  prioritizing  must  take  place  to  ensure  that  service  is  maintained 
and  restored  to  as  many  people  as  possible  in  the  shortest  amount  of  time.  In  accomplishing  this 
goal,  the  service  dispatcher  must  prioritize  daily  work  schedules,  assign  jobs  to  field  units,  and 
monitor  the  progress  of  all  field  workers.  Additionally,  during  the  evening  hours,  the  service 
dispatcher  becomes  the  only  service  operator  on  duty,  increasing  the  amount  of  coordination 
required. 
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Figures.  Bitmap  of  Geographic  Area. 


4.  Distribution  Operator 

The  distribution  operator  is  one  of  the  key  safety  coordinators  for  all  maintenance  actions. 
When  a  field  worker  needs  to  perform  maintenance  on  a  particular  section  of  line,  the 
distribution  operator  ensures  that  the  maintenance  is  performed  safely.  The  operator  does  this  by 
referencing  a  checklist  of  maintenance  steps  wdiile  the  field  worker  is  performing  the 
maintenance.  While  doing  this,  s/he  must  also  make  sure  that  the  power  to  the  effected  line  is 
secured,  and  that  it  is  safe  for  the  field  woricer  to  proceed.  Distribution  Operator  Video  (see 
Figure  9). 


Figure  9.  Distribution  Operator  Video. 


Figure  10.  Bitmq)  of  Service  Tag. 
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5.  Grid 

What  is  commonly  referred  to  as  the  "grid"  is  in  fact  the  layout  of  all  the  electrical  lines 
throughout  the  city.  Grid  (see  Figure  1 1 ) 


Figure  1 1 .  Bitnu^  of  Power  Grid. 


The  power  grid  is  made  up  of  substations,  lines,  circuit  breakers,  switches,  and  fuses. 
Switches  and  Fuses,  (see  Figure  12).  This  grid  is  in  turn  laid  over  a  map  of  the  geographic  area, 
allowing  for  isolation  of  individual  residences  or  businesses  that  may  be  experiencing  problems. 
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6.  Switches  And  Fuses 
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Substations  are  the  sources  for  the  power  that  goes  out  on  a  particular  line.  The  line, 
typically  21,000  volts,  carries  the  power  throughout  the  area  for  distribution.  Smaller,  1000  volt 
lines  feed  off  of  the  21  kilovolt  lines  and  step  down  to  distribute  electricity  to  individual 
residences  and  business.  On  each  of  these  high  and  low  power  lines  are  circuit  breakers, 
switches,  and  fuses.  These  devices  protect  the  equipment  from  surges  and  underages  of  power, 
which  can  cause  damage  to  vital  equipment. 
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7.  Current  Switching  Method 

During  a  global,  large  scale  outage,  workers  must  progressively  switch  on  and  off  the 
switches  within  the  system  in  order  to  isolate  where  the  problem  is  located.  Once  the  problem 
has  been  located,  only  then  may  woric  proceed  in  order  to  restore  service.  This  is  typically  a  very 
time  consuming  endeavor,  requiring  a  great  deal  of  coordination  and  manpower.  When  woric  or 
maintenance  needs  to  be  performed  on  a  particular  line,  a  field  woricer  must  go  out  to  the  circuit 
breakers,  switches,  or  fuses  directly  upstream  and  downstream  from  the  affected  piece  of 
equipment,  and  manually  switch  them  off  to  isolate  the  line.  Once  this  has  been  accomplished, 
then  work  on  that  line  or  piece  of  equipment  may  proceed.  Current  Switching  Method  Video 
(see  Figure  13). 


Figure  13.  Video  of  engineer  explaining  current  switching  method. 
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8.  Intelligent  Switches  and  Fuses 

The  company  has  begun  to  replace  its  old  technology  Switches  And  Fuses  (see  Figure 
12)  with  new,  "intelligent"  switches  and  fuses.  Intelligent  Switches  Video  (see  Figure  14). 
These  new  devices  can  be  controlled  via  the  telephone,  automatically  switching  on  or  off  >^en 
receiving  the  appropriate  code.  This  will  greatly  reduce  the  required  manpower  to  isolate 
problem  spots  on  the  grid.  These  switches  are  denoted  on  the  power  grid  map  with  the  "TC" 
code,  which  means  telephone  controlled. 


igure  14.  Video  of  Engineer  explaining  intelligent  fuses. 
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B.  USING  REMAP/MM  DURING  SYSTEM  ANALYSIS 

The  following  section  of  the  example  illustrates  REMAP/MM's  use  during  the  system 

analysis  phase.  In  the  scenario,  the  analysts  are  engaged  in  a  deliberation  on  a  requirement  for 
processing  service  orders.  (The  deliberation  in  terms  of  REMAP  primitives  is  shown  in  Figure 
15.)  Three  issues  that  ate  raised  by  the  team  members  are: 

•How  should  calls  be  handled? 

•How  are  service  orders  prioritized? 

•How  are  service  orders  tracked? 

The  deliberation  involves  verifying  positions  or  alternatives  that  solve  the  issues  and 
arguments  behind  them,  and  their  underlying  assumptions.  We  briefly  describe  how  various 
multimedia  segments  of  the  discussion  are  incorporated  in  the  design  rationale  knowledge. 

1.  Process  Service  Order  Information 

A  primary  requirement  is  that  the  system  should  be  able  to  handle  incoming  calls, 
establish  priorities  among  the  calls,  and  track  the  calls  once  they  have  been  answered.  Many 
customers  require  up  to  date  and  accurate  information  in  order  to  make  important,  sometimes  life 
or  death,  decisions.  For  example,  a  residential  customer  may  be  reliant  on  an  electrically 
operated  medical  device.  She  could  not  survive  for  more  than  five  hours  without  tiiis  device. 
This  customer  needs  to  know  when  the  power  will  be  restored,  so  a  decision  can  be  made  as  to 
whether  or  not  to  move  to  a  location  where  electricity  is  still  available. 
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Figure  IS.  Process  Service  Order  Information  Overview. 

a.  How  Should  Calls  Be  Handled?  (Issue) 

The  primary  interface  between  tl^  company  and  the  customer  is  through  service 
calls.  Meeting  the  needs  of  the  customer  is  the  con^rany's  main  goal,  and  achieving  this  can  best 
be  accomplished  by  effectively  and  efficiently  handling  incoming  calls.  The  issue  of  importance 
here  is  how  to  haiulle  incoming  calls. 

L  Human  Operator  position) 

The  first  position  is  that  the  calls  should  all  be  handled  by  a  human 
operator,  >^o  will  take  information  and  route  the  call  manually. 

iL  Personal  Interaction  (Argnmmit) 

The  operator  is  the  only  person  that  the  customer  will  interact  widi.  All  of 
the  customer's  perceptions  about  the  company  are  based  on  their  experiences  wifii  the  phone 
operators.  For  this  reason,  human  operators  are  preferable  to  automated  systems.  Computer 
systems  cannot  provide  the  personal  touch  that  customers  prefer. 
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iiL  Current  Answeriog  Methoib  (Armament) 

The  current  system  of  call  handling  is  operator  interaction  widi  tl^ 
customer.  An  automated  system  would  add  costs  to  die  established  system,  aiKl  would  degrade 
the  company's  public  image  both  among  its  employees  and  the  general  public. 

hr.  Computer  Routing  (Position) 

Computer  routing  allows  the  customer  to  indicated  udiat  type  of  service  is 
required  before  having  to  talk  with  an  operator. 

V.  Yoke  Mail  (Aignment) 

A  voice  mail  system  would  allow  the  customer  to  leave  a  message 


indicating  udiat  type  of  service  is  required,  allowing  the  operators  to  handle  more  urgent  calls 
direcdy.  Voice  Mail  Discussion  (see  Figure  16). 


Figure  16.  Video  of  voice  mail  discussion. 


vL  Time  Critical  Calb  (Argamcnt) 

Most  calls  that  come  in  to  the  service  center  are  not  of  a  critical  nature. 

By  using  a  computer  routing  system  that  breaks  out  calls  by  their  type  (billing,  maintenance, 
service,  etc.),  operators  will  be  able  to  spend  more  time  handling  critical  calls. 

b.  How  Are  Service  Orders  Prioritized?  (Issue) 

IDue  to  company  down-sizing  and  shrinking  fiscal  resources,  the  company  must 
develop  a  priority  scheme  to  better  serve  the  customers'  needs.  The  issue  is  v/hst  is  the  best 
method  to  prioritize  incoming  service  requests? 

L  Service  Type  (PositioB) 

Calls  should  be  prioritized  by  the  type  of  service  required  by  the  customer, 
i.e.,  emergency  service,  billing  service,  or  maintenance  service. 

iL  Service  Required  (Anpuneut) 

By  prioritizing  calls  according  to  service  type,  emergency  situations  can 

be  handled  immediately,  allowing  for  timely  resolution  of  service  problems.  Less  vital  services 

such  as  billing  will  still  be  handled  expediently,  but  t^ien  an  emergency  arises,  q)propriate 

resources  can  be  immediate  focused,  possibly  (xeventing  damages  and  losses. 

iiL  Computer  Routing  (AssumptioB) 

A  computer  routing  system  is  being  used  to  handle  initial  calls. 

iv.  Customer  Type  (Position) 

Calls  should  be  prioritized  the  type  of  customer,  either  industrial  or 

residential. 
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V.  Specialization  (Argnment) 

Prioritizing  under  this  scheme  would  allow  the  field  workers  to  specialize 
in  various  areas  of  service.  Industrial  customers  have  needs  that  differ  from  residential 
customers. 

vi  Computer  Routing  (Assiunption) 

A  computer  routing  system  is  being  used  to  handle  initial  calls. 

vii  Equipment  (Argument) 

There  are  different  material  and  equipment  requirements  for  each  type  of 
customer.  By  prioritizing  by  customer  type,  this  equipment  may  be  centrally  managed  and 
accounted  for,  reducing  the  company's  costs. 

viiL  Computer  Routing  (Assumption) 

A  computer  routing  system  is  being  used  to  handle  initial  calls. 

c.  How  Are  Service  Orders  Tracked?  (Issue) 

The  status  of  all  service  calls  must  be  tracked  and  iqxlated,  to  allow  for  timely 
customer  notification.  How  these  calls  should  be  tracked  is  die  issue. 

L  Current  Method  (Position) 

Currently,  all  calls  are  manually  tradced  by  placing  follow-iq)  calls  for 
every  service  tag  generated.  This  method  guarantees  that  all  customers  are  given  return  calls 
iqxlating  them  on  the  status  of  their  service 

iL  Manual  Tracking  (Alignment) 

The  current  method  of  tracking  orders  is  satisfactory,  and  performs  well. 
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uL  Computer  Storage  (Position) 

A  database  system  of  call  storage  should  be  implemented  to  help  track 
orders.  Computer  Storage  Video  (see  Figure  17). 

iv.  Automated  Tracking  (Argument) 

The  new  system  should  store  calls  on  a  centralized  database  without 
actually  generating  the  tags.  When  service  has  been  restored,  the  computer  should  be  able  to 
automatically  dial  the  customer  back,  and  let  the  operator  iqxlate  the  customer.  This  will  greatly 
reduce  the  time  demands,  because  the  tags  will  not  have  to  be  manually  sorted  and  rechecked. 


Figure  17.  Video  of  computer  storage  discussion. 
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C.  USING  REMAP/MM  IN  THE  DESIGN  PHASE 

The  following  is  an  example  use  of  REMAP/MM  during  the  design  phase  of  system 
development.  During  this  phase,  the  development  team  is  engaged  in  discussions  concerning  the 
specific  design  mechanisms  to  process  service  tags.  The  issues  being  considered  are; 

'How  to  get  customer  records? 

•How  should  the  service  operator's  screen  be  organized? 

•How  should  service  tags  be  screen?. 

(These  deliberations  are  shown  in  terms  of  REMAP  primatives  in  figure  18.)  These 
deliberations  identify  and  solve  issues  concerning  the  design  phase  of  the  project.  Included  in 
this  section  are  descriptions  of  how  the  multimedia  segments  are  incorporated. 
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1.  Process  Service  Tags 


Figure  18.  Process  Service  Tags  Overview. 


Automating  the  processing  of  the  service  tags  should  provide  the  company  with  the 

following  information: 

1)  Grid  customer  is  on. 

2)  Feeder  Number  of  customer. 

3)  Is  this  an  isolated  event  or  a  global  outage? 

It  is  required  that  the  system  show  that  it  can  provide  the  above  information  faster  and 
with  fewer  people  involved  in  the  process. 


a.  How  to  Get  Cnstomer  Record?  (Issue) 

A  customers  record  contains  a  variety  of  information.  Customer  address,  phone 
number,  and  account  number  are  the  basics.  Included  in  the  record  is  vdiat  grid  the  customer  is 
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on,  the  feeder  number,  maintenance  historical  records,  as  well  as  all  billing  information.  Some 
of  this  information  is  added  to  the  newly  generated  tag.  The  issue  is:  How  should  the  customers 
record  be  retrieved? 


L  Entire  Record  (Position) 

The  entire  record  should  be  retrieved  by  the  customer  service  operator  at 
the  time  of  the  phone  call.  If  a  service  tag  is  to  be  generated  by  the  call,  the  ^propriate 
information  will  be  added  to  the  tag  at  that  time.  The  operator  will  be  able  to  verify  the 
correctness  of  the  address  as  well. 


Figure  19.  Video  of  Drill  Down  interfiu^. 

If  the  call  is  a  request  for  billing  infonnation,  it  can  be  handled  at  that 
time.  All  of  the  customer’s  information  is  already  there.  Not  all  of  the  information  need  be 
displayed  at  all  times.  The  operator  should  have  the  ability  to  "drill  down"  to  more  detailed 
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information  as  it  is  needed.  Drill  Down  Interface  Video  (see  Figure  19).  For  this  reason,  the 

information  should  be  retrieved  and  ready  tc  display  for  whatever  the  situation  is. 

ii.  Better  Customer  Relations  (Argument) 

When  a  customer  calls  in,  the  call  is  posted  on  the  Call  Status  Board.  Call 

Status  Board  Video  (see  Figure  20).  The  operator  has  no  idea  of  what  the  customer  is  calling 

about  until  she  gathers  more  information.  Because  the  operator  is  the  main  interface  between  the 

company  and  the  customer,  the  operator  should  have  quick  and  ready  access  to  all  of  that 

customer's  information.  At  any  given  time,  the  customer  could  be  calling  about  a  billing 

problem,  a  power  outage,  or  a  maintenance  problem.  For  this  reason,  the  operator  needs  to  be 

able  to  instantly  retrieve  each  of  these  types  of  data.  The  most  efficient  and  expedient  way  of 

doing  this  is  to  retrieve  the  entire  record  as  soon  as  the  call  is  taken. 

iiL  Good  Public  Relations  (Assumption) 

Good  public  relations  is  important  in  this  industry  due  to  constantly 

increasing  costs.  The  operators  are  the  primary  communicators  and  representatives  for  the 

company,  and  hence  must  be  ciq)able  of  handling  nearly  any  situation  that  could  arise  over  the 

phone. 

iv.  FiU  In  x'f  ame  And  Address  Of  Customer  (Position) 

If  a  service  tag  is  to  be  generated  from  this  call,  the  information  for  the  tag 

A 

can  be  obtained  during  the  tag  processing,  not  during  the  phone  call.  Only  the  name,  address, 
and  phone  number  of  the  customer  are  needed  and  these  can  be  obtained  by  the  operator  at  that 
time.  If  there  is  a  billing  problem,  then  just  the  billing  information  of  the  customer  needs  to  be 
retrieved. 
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V.  Faster  Process  (Argument) 

By  not  having  to  retrieve  the  entire  customer  record  every  time  a  phone 
call  comes  into  the  service  operator  center,  more  calls  can  be  handled,  providing  better  service  to 
the  customer. 


Figure  20.  Video  of  Call  Status  Board. 


b.  How  Should  The  Service  Operator  Screen  Be  Organized?  (Issue) 

Do  the  computer  interfaces  used  by  service  operators  need  to  be  redesigned  to 

better  streamline  the  new  automated  process?  Current  Screen  Interface  Video  (see  Figure  21). 

L  Nine  To  Ten  Categoric  For  The  Operator  To  Choose  From 

(Position) 

The  screen  used  by  the  service  operators  should  have  a  list  of  9  to  10 
categories  for  the  operators  to  classify  a  maintenance  request  under. 

iL  Current  Tag  Setup  9-10  Categories  For  The  Operator  To  Choose 

From  (Argpment) 

Ninety  nine  percent  of  all  problems  fall  under  these  specified  categories. 
The  maintenance  people  will  not  use  any  more  information  than  the  basics  anyway.  This  is  also 
the  current  interface  setup.  No  new  training  required. 
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Figure  21.  Video  of  current  screen  interface. 


iiL  Operator  Fill  In  Text  (Position) 

The  screen  should  have  the  basic  address  information  for  the  operator  to 
confirm  correct.  Then  have  a  text  box  for  the  service  operator  to  type  in  a  description  of  the 
problem.  This  will  allow  for  precise  descriptions  of  the  problem,  reducing  the  troubleshooting 

time  required  by  the  field  workers. 

iv.  More  Information  (Aipiment) 

The  more  information  describing  the  problem  on  the  tag  will  help  the 
maintenance  people  understand  the  problem  better  before  actually  talking  to  the  customer 
themselves. 

v.  Good  Typists  (Assumption) 

All  the  service  operators  are  good  typists,  so  this  will  not  slow  the  process 

down  any. 


vL  One  Sized  Text  Box  (Assumptions) 

One  set  sized  text  box  will  be  able  to  handle  any  description  made  by  a 

customer. 

c.  How  Should  The  Service  Tags  Be  Screened?  (Issue) 

The  manual  screening  process  that  is  used  currently  is  just  too  slow.  This  process 

must  be  automated.  Each  tag  will  have  on  it  the  customers  grid  number,  as  well  as  source  side 

device  tag  number.  The  data  base  must  be  able  to  screen  the  tags  and  sound  an  alert  if  there 

seems  to  be  a  global  outage  occurring. 

L  Screen  AU  Tags  Generated  In  The  Last  30  Minutes  (Position) 

If  a  tag  for  a  complete  electrical  failure  is  generated,  it  needs  to  be 

compared  to  any  tag  with  a  similar  complaint  to  determine  if  this  is  an  isolated  event  or  not.  If 

not,  then  there  is  a  possibility  of  a  global  Mlure.  One  method  suggested  to  determine  this  would 

be  to  compare  the  tag  to  those  tags  generated  in  die  last  30  minutes. 

ii.  Fewer  Tags  Generated  (Argument) 

This  comparison  will  allow  fewer  tags  to  be  generated  if  there  is  a  global 

outage. 

UL  Last  10  Tags  (Position) 

Power  failure  tags  need  to  be  compared  with  the  last  10  tags  regardless  of 
time  in  order  to  detect  a  global  failure. 

« 

iv.  Easier  MeBiod  (Argument) 

This  is  a  easier  method  to  implement  and  it  gets  the  same  job  done.  Fewer 

tags  will  be  generated. 
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IV.  RECOMMENDATIONS  AND  CONCLUSIONS 


As  a  system  develops,  the  documentation  that  is  produced  becomes  the  formal 
memory  of  the  project  What  is  missing  from  this  memory  is  the  reasoning  behind  the 
decision  that  produced  the  end  product.  This  design  rationale  is  a  vital  component  of  any 
complex  design.  Examining  the  design  rationale  of  a  complex  system  can  lend  greater 
insight  and  understanding  to  the  system,  and  can  be  ^lied  to  future  system  upgrades  or  new 
projects. 

Design  rationale  produces  numerous  artifacts  winch,  wlien  properly  captured,  can 
assist  future  design  team  members  in  recreating  con^lex  decisions  and  the  reasoning  behind 
them.  The  REMAP/MM  model  for  capturing  design  rationale  provides  a  graphical  interfoce 
for  the  design  team  to  use  in  their  deliberations.  This  model,  through  the  use  of  hypertext 
documentation,  allows  the  team  member  to  quickly  locate  issues  that  have  been  deliberated 
over,  and  examine  their  rationale.  The  user  will  be  able  to  use  written  documents, 
photographs,  video  clips,  voice  clips,  or  any  other  media  for  c^>turing  tiie  design  rationale. 

REMAP/MM  provides  the  user  with  the  ability  to  seamlessly  transition  from  a 
gr^hical  representation  of  the  decision  process  to  the  actual  multimedia  artifact  that  was 
c£q)tured  during  the  deliberations  of  the  issue.  Such  a  frdlity  should  greatly  increase  the 
productivity  of  future  designers. 

The  example  developed  for  this  thesis  illustrates  the  effective  cq>ture  of  a  wide 
variety  of  artifacts,  such  as  video,  bitnuqis,  and  sound  clips.  The  complexity  of  designii^  a 
large  scale  service  order  processing  system  for  a  la^e  power  company  can  easily  be 
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i  .ed.  A  system  of  this  complexity  would  typically  require  three  to  five  years  to  fully 
develop  and  reach  implementation.  The  example  only  addresses  two  of  the  relatively  small 
sub-processes  of  the  entire  system.  It  is  beyond  the  scope  of  this  work  to  include  a 
"complete"  example  of  design  rationale  for  this  system.  However,  the  example  is  intended  to 
highlight  the  important  characteristics  of  a  multimedia  based  design  rationale  system.  A 
study  of  such  technology  would  consist  of  a  longitudinal  study  over  the  entire  life  cycle, 
addressing  both  cfq)ture  and  use  of  design  rationale. 

A  great  deal  of  time  and  domain  knowledge  is  required  to  determine  wliat  type  of 
artifacts  should  be  captured  using  multimedia.  For  instance  video  tq>ing  a  design  meeting 
often  does  not  effectively  c^ture  all  the  reasoning  behind  certain  decisions  made  during  the 
meeting.  Additionally,  keeping  the  entire  meeting  on-line  is  currently  impractical. 

Significant  time  and  effort  is  required  to  effectively  glean  the  vital  decision  process 
information  fix)m  the  vast  amount  of  data  that  is  communicated  during  a  meeting.  Although 
the  example  for  this  thesis  is  relatively  small,  hours  of  video  and  other  artifacts  were 
generated.  This  required  a  tremendous  amount  of  editing  and  analysis  to  determine  ^diat 
artifacts  represented  useful  design  rationale.  It  is  our  recommendation  that  once  a  important 
decision  has  been  made,  the  design  rationale  artifacts  that  led  to  that  decision  should  be 
immediately  documented.  This  would  prevent  the  loss  of  important  information,  and  allow 
for  a  more  accurate  representation  of  the  decision  process. 
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